home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / mac / files / p_thenet / x1j.exe / OVERVIEW.TXT < prev    next >
Text File  |  1993-08-05  |  72KB  |  1,508 lines
  1.                               TheNet X-1J
  2.  
  3.                          Overview of Operation
  4.  
  5. 1. INTRODUCTION
  6.  
  7.      This  paper  introduces the main features of TheNet X-1J.  This  is  an 
  8.      update to the previous paper on version X-1H, and includes a number  of 
  9.      changes including the following : 
  10.  
  11.           * Support for a simple receive signal deviation meter
  12.           * Control over 'slime trailing'
  13.           * Info, BText and CText messages may span several lines
  14.           * Nodes broadcasts occur 60 seconds after power-up
  15.           * An  optional 'reconnect to node' following remote disconnect  is 
  16.             supported
  17.           * PARMS,  MODE etc may be changed with offset & new value  instead 
  18.             of '* * * 'etc
  19.           * Optional control over digi uplink & downlink is supported
  20.           * Transport retries ( min ) has been dropped to 1
  21.           * an MTU command has been added to allow easy changes to MTU sizes 
  22.             for IP users
  23.           * Information Messages in RAM may be up to 160 bytes long
  24.           * The  TALK  command  may be set to pass 8  bit  data  instead  of 
  25.             clearing bit 8
  26.           * Node aliases, at the switch, may be made case sensitive
  27.  
  28.      The  software is a derivative of TheNet 1.01 by NORD><LINK.  Additional 
  29.      commands and bug fixes have been included in the release. In  addition, 
  30.      the Patcher has been upgraded and a bug fix to MOTOROLA.C  attributable 
  31.      to KH6ILT has been included.
  32.  
  33.      If your reaction is 'What I really want is ......', then please read on 
  34.      anyway, especially section 6.
  35.  
  36. 2. STRUCTURE
  37.  
  38.      One  of the problems to extending TheNet is the 32 K  EPROM  limitation 
  39.      imposed by the architecture of TNC2 clones. The solution to this is  to 
  40.      implement bankswitching. For the BSX2 TNC and similar TNC2 clones, this 
  41.      can  be  achieved by the addition of a single wire as detailed  in  the 
  42.      bankswitch  modification file. This is at the expense of the  HIGH  and 
  43.      LOW commands. The other version that was previously available with HIGH 
  44.      and  LOW  in it is no longer supported as it is incompatible  with  the 
  45.      deviation meter.
  46.  
  47.  
  48. 3. NEW COMMANDS
  49.  
  50.      The following commands have been added to the release
  51.  
  52.                BYE
  53.                BBS
  54.                HOST
  55.                STATS
  56.                MHEARD
  57.                MODE
  58.                MANAGER
  59.                AUDIT
  60.                TALK
  61.                CALIBRATE
  62.                LINKS
  63.                ACL
  64.                CLOSEDOWN 
  65.                BTEXT
  66.                DXCLUSTER
  67.                HELP
  68.                CTEXT
  69.                ALIAS
  70.                BBSALIAS
  71.                HOSTALIAS
  72.                DXCALIAS
  73.                QUIT
  74.                IPROUTE
  75.                ARP
  76.                IPSTATS
  77.                IPADDRESS
  78.                IPBROADCAST
  79.                UI
  80.                MTU
  81.                METER
  82.  
  83.      The following commands have been changed
  84.  
  85.                CQ
  86.                NODES
  87.                RESET
  88.                the <escape> commands
  89.                SYSOP
  90.  
  91.      The following features have been added to the code
  92.  
  93.                An Internet Router
  94.                Ability to respond to three additional aliases
  95.                ACWID keyer
  96.                The command processor has been extended
  97.                KISS mode operation on the RS232 port
  98.                HOST mode support on the RS232 port
  99.                Remote configuration of all parameters
  100.                Additional textual help messages
  101.                Support for a 4 channel ADC used for measuring RX deviation
  102.                Other changes as detailed herein.
  103.  
  104.      In addition, a number of small changes have been implemented to satisfy 
  105.      the  needs of specialist situations such as the ability to digi  beacon 
  106.      packets.
  107.  
  108.      Network  management  in  this  context  does  not  just  mean  'setting 
  109.      parameters  remotely'. It means the ability to set, read and  interpret 
  110.      various monitors and diagnostic tools. Version X-1C included the  first 
  111.      part  of  the network management, the MANAGER privilege and  the  AUDIT 
  112.      process. Version X-1D extends the auditing and statistics significantly 
  113.      including  internal  CPU monitors. Version X-1E includes  most  of  the 
  114.      additions that are planned, and version 2 will complete the  functions. 
  115.      No other release before version 2 was planned, but the need to  produce 
  116.      a version with an IP router has prompted this release. The  opportunity 
  117.      to  experiment with additional features was therefore taken.  The  next 
  118.      version  was  intended to include significant changes  attributable  to 
  119.      Hayden Bate G8AMD, but again due to other requirements, another interim 
  120.      version has been produced ( the main driver being the need locally  for 
  121.      the Deviation Meter ).
  122.  
  123. 3.1 BYE or QUIT
  124.  
  125.      There are no parameters to these commands. When entered, they terminate 
  126.      the session. Both commands do the same thing.
  127.  
  128. 3.2 BBS
  129.  
  130.      The syntax of the command is :
  131.  
  132.                BBS [ * | ? | callsign ]
  133.  
  134.      With  no  parameter,  the  command connects  to  a  station  previously 
  135.      specified by the sysop. Setting the BBS destination is done by the  use 
  136.      of  the BBS command with a callsign as a second parameter. Setting  the 
  137.      BBS to allow this may only be done by a sysop. The '*' option may  also 
  138.      only  be  executed  by  the sysop, this  command  clears  a  previously 
  139.      specified BBS.
  140.  
  141.      The '?' option ( or any text if not sysop ), prints out the current BBS 
  142.      station setting.
  143.  
  144.      If no BBS is set, the command issues an error message if it is  invoked 
  145.      with no other parameters.
  146.  
  147.      The  idea of this command is that, like with the 'BBS' command  of  the 
  148.      'BPQ software, a user may connect to the local BBS from the node.
  149.  
  150. 3.3 HOST
  151.  
  152.      The syntax of the command is :
  153.  
  154.                HOST [ * | ? | callsign ]
  155.  
  156.      This command is very similar to the 'BBS' command. It allows connection 
  157.      to  a local host, BBS or other server. The difference however, is  that 
  158.      as long as the TNC is not in 'crosslink' mode ( ie pin 23 on the  RS232 
  159.      port  is  high  ), and if a callsign is not  set,  the  'host'  command 
  160.      connects to the local port.
  161.  
  162.      The  idea of this command is that, like with the 'BBS' command  of  the 
  163.      'BPQ  software,  a user may connect to the local BBS, another  node  or 
  164.      server from this node. For example, if a print server were connected to 
  165.      the  node in 'host' mode, this command would allow connection to  it  ( 
  166.      like  the  'connect' command with no other parameter ). In  KISS  mode, 
  167.      setting a callsign or node alias allows connection to another system.
  168.  
  169. 3.4 STATS
  170.  
  171.      The STATS command has no parameters. It prints a number of internal TNC 
  172.      statistics.  In this version, this is limited to the level 1  stats  of 
  173.      the radio channel and the internal clocks, the level 2 ( AX.25 ), 3 and 
  174.      4 statistics, and the CPU health checks.
  175.  
  176.      For  level  1, six pairs of numbers are printed, corresponding  to  the 
  177.      percentage of time the transmitter was on followed by the percentage of 
  178.      time  the  receiver  DCD was on, for each of the  last  six  10  minute 
  179.      periods.  The data is presented most recent period first. Two pairs  of 
  180.      numbers  are  then  displayed  showing  the  transmitter  underrun  and 
  181.      receiver  overrun.  These are formatted as per the level 2  stats  with 
  182.      port  0 followed by port 1 for the current hour followed by the  totals 
  183.      for the previous hour. In the case of the RS232 port, underruns are not 
  184.      possible,  and  an  additional error ( framing ) is  included.  The  RX 
  185.      overrun includes overruns and framing errors.
  186.  
  187.      For level 2, the following are displayed :
  188.  
  189.                Frame checksum errors
  190.                Total packets heard
  191.                Total packets received by the node ( ie sent to it )
  192.                Total packets sent by the node
  193.                Total receiver not ready packets sent
  194.                Total reject packets sent
  195.                Total receiver not ready packets received
  196.                Total reject packets received
  197.                Total number of link timeouts
  198.  
  199.      For  each of the level 2 statistics, four numbers are shown. The  first 
  200.      two are cumulative totals over the period of one hour, incrementing  in 
  201.      real time. The last two are the totals for the previous hour. Each pair 
  202.      of  numbers is the total for the radio port followed by the  total  for 
  203.      the RS232 ( crosslink ) port. 
  204.  
  205.      For checksum errors, port 0 shows CRC errors and port 1 shows ( when in 
  206.      'crosslink'  protocol mode only ), checksum errors. As HDLC errors  can 
  207.      be  triggered by noise, acceptance of CRC errors is conditioned by  the 
  208.      state of the DCD line. If DCD is on and an error is signalled, it  will 
  209.      be  added  to the count. This reduces the false counts,  but  does  not 
  210.      eliminate  them. Distant stations that keep the squelch open (  just  ) 
  211.      without being properly heard will result in lots of apparent errors.
  212.  
  213.      For  level 3, the number of level 4 frames gatewayed between  nodes  is 
  214.      displayed.
  215.  
  216.      For  level 4, the number of transport frames sent and received  by  the 
  217.      node are shown.
  218.  
  219.      For  level 3 and 4 statistics, two numbers are shown. The first is  the 
  220.      number  of frames accumulating for this hour, and the second number  is 
  221.      the total number of frames for the previous hour.
  222.  
  223.      For CPU health checking, two statistics are shown, the CPU loading  and 
  224.      the  buffer  usage. Each looks like the level 1 stats  with  6  numbers 
  225.      corresponding to the last six 10 minute periods. 
  226.  
  227.      The CPU loading shows the number of times, divided by 100, that the CPU 
  228.      makes it around its basic internal scheduler. For a node just  switched 
  229.      on, receiving nothing, this will be about 470 ish for a 4.9 MHz  clock. 
  230.      With lots of nodes, a heard list of 20 stations and 70-80% activity  on 
  231.      the  radio channel for it to listen to, this can drop to about  350ish. 
  232.      If  it  drops  to double figures, worry, as the  CPU  is  beginning  to 
  233.      thrash. At low double figures, the CPU is pretty much working  flatout. 
  234.      Time to up its clock rate !.
  235.  
  236.      The BUFFERS statistic shows the minimum number of free buffers that the 
  237.      software had available to it during the last six 10 minute period. This 
  238.      indicates  whether the TNC is failing to deliver data passed to it  for 
  239.      onwards  transmission, as well as how much data is backed  up  waiting. 
  240.      Additional  stats  needed to analyse this properly are  not  yet  being 
  241.      collected.
  242.  
  243.      The  display  also  shows the elapsed time  since  the  last  warmstart 
  244.      followed  by the running time since the last coldstart. Each number  is 
  245.      the number of hours of operation.
  246.  
  247. 3.5 MODE
  248.  
  249.      This  command  is similar to the PARMS command, and  includes  the  new 
  250.      syntax described in section 3.32.
  251.  
  252.      It  allows a number of other features of the software to be  configured 
  253.      remotely.  It  removes  the need for most of  the  host  mode  <escape> 
  254.      commands.
  255.  
  256.      The following parameters may be configured :
  257.  
  258.                The host mode
  259.                The CWID send period
  260.                The CWID keyer speed
  261.                The port nodes broadcast control
  262.                The crosslink / kiss control
  263.                The Tx delay
  264.                The full duplex flag
  265.                The RS232 port node broadcast interval
  266.                The node broadcast algorithm
  267.                The beacon period
  268.                The 'connect' redirector
  269.                The 'help message enable' flags, case  sensitivity 
  270.                    & TALK 8 bit flag
  271.                The 'hash' node broadcast port control
  272.                Whether the node will listen for the extra aliases
  273.                Whether remote disconnect causes reconnection to the switch
  274.                Control over 'slime trails'
  275.                Control over digipeating up/down links
  276.  
  277.      In operation, it behaves just like the PARMS command.
  278.  
  279.      The parameters are as follows :
  280.  
  281. 3.5.1 Host mode control
  282.  
  283.      This parameter controls the 'host' mode. This is the mode of  operation 
  284.      of the RS232 port when pin 23 is 'high'
  285.  
  286.      The valid values are 0 or 1.
  287.  
  288.      In  mode 0, the port operates as per the standard  node  specification. 
  289.      Mode  1 is designed to allow connection to hosts or modems  or  similar 
  290.      equipment  that  expects  a  'CD' type of signal  to  signify  that  an 
  291.      incoming / outgoing connection is called for.
  292.  
  293.      In mode 1, the <escape> C and <escape> D commands are disabled and  the 
  294.      other  <escape>  commands  do  not  operate  when  connected.  Instead, 
  295.      hardware  handshakes  are used to control connections to and  from  the 
  296.      TNC.
  297.  
  298.      The TNC monitors pin 20 to determine the state of the host, and signals 
  299.      state changes to the host with pin 5. When an incoming connect  request 
  300.      is  received ( by the 'c' command with no parameters or by  the  'host' 
  301.      command  ), the TNC raises pin 5 to signal the connection  and  expects 
  302.      pin 20 to change state in response.
  303.  
  304.      When  the host wishes to connect to the TNC, it signals on pin  20  and 
  305.      the TNC responds with by changing the state of pin 5.
  306.  
  307.      It handles disconnects in a similar manner. Either the node or the host 
  308.      may initiate disconnects.
  309.  
  310.      This mode is experimental, changes may be made to its operation. It  is 
  311.      designed  for  modems, print servers or hosts such as UNIX  system  TTY 
  312.      login drivers.
  313.  
  314. 3.5.2 CWID control
  315.  
  316.      The next two parameters control the CWID keyer. 
  317.  
  318.      The first parameter is the CWID repeat period in seconds. Valid  values 
  319.      are 0 to 3600. 0 disables it but do not set it below 120 apart from  to 
  320.      disable it.
  321.  
  322.      The  second parameter controls the keyer speed. Specifically,  it  sets 
  323.      the  number  of  10 millisecond periods per dot and  per  inter  symbol 
  324.      delay.
  325.  
  326.      The  speed of sending is 120/n, so setting n to 6 gives 20  wpm.  Valid 
  327.      values  are  4  to  10,  corresponding to  speeds  of  30  and  12  wpm 
  328.      respectively.
  329.  
  330. 3.5.3 Node broadcast control
  331.  
  332.      This  parameter allows control to be exercised over which  ports  nodes 
  333.      broadcasts are sent. Valid settings are 0 - 3.
  334.  
  335.      Value  0  disables node broadcasts. Value 3 ( the default  )  works  as 
  336.      normal. A value of 1 enables broadcasts on the HDLC port only whilst  a 
  337.      value of 2 enables broadcasts on the crosslink port only.
  338.  
  339. 3.5.4 Crosslink / kiss
  340.  
  341.      This  parameter is used to set the communications protocol used on  the 
  342.      crosslink port when pin 23 is tied low.
  343.  
  344.      The valid values are 0, 1, 2 or 3 
  345.  
  346.      Mode 0 - standard crosslink protocol enabled
  347.      Mode 1,2,3 - use KISS instead of crosslink.
  348.  
  349.      In  mode  1,  KISS simply replaces the crosslink protocol  In  mode  2, 
  350.      packets received from the radio part that are not intended for the node 
  351.      are  copied to the RS232 port in KISS mode. Similarly packets  received 
  352.      on  the RS232 port that are not intended for the node are sent  to  the 
  353.      radio port.
  354.      In  mode  3, all packets received on one port are copied to  the  other 
  355.      port as well as being analysed by the node.
  356.  
  357.      These modes are not simply KISS implementations that replace the  node, 
  358.      they run with the node.
  359.  
  360.      Mode  2 is designed to allow a KISS application and a node to  share  a 
  361.      radio  without interference with each other. The point is that  the  PC 
  362.      TCP/IP  system can be switched off whilst leaving the node  running  to 
  363.      allow others to use it.
  364.  
  365.      Mode 3 is a debugging mode. One problem when faultfinding on a node  is 
  366.      that  it  is impossible to see what the node is seeing on  the  channel 
  367.      without  replacing  the ROM. By setting this mode, it  is  possible  to 
  368.      connect a KISS application to the RS232 port and observe what the  node 
  369.      is seeing.
  370.  
  371.      Mode  3 is also designed to allow a PC running AXSTATS to be  connected 
  372.      to the RS232 port to allow logging and analysis of channel  performance 
  373.      from  the node itself. Note that packets initiated by the node for  one 
  374.      port will not get copied to the other.
  375.  
  376. 3.5.5 Tx keyup delay
  377.  
  378.      This  parameter sets the TX keyup delay in 10's of  milliseconds.  This 
  379.      was previously done using an escape command.
  380.  
  381. 3.5.6 Full Duplex
  382.  
  383.      This  parameter sets or clears the full duplex control flag.  This  was 
  384.      previously done using an escape command.
  385.  
  386. 3.5.7 RS232 nodes broadcast interval
  387.  
  388.      When a crosslinked TNC is reset, it takes some time to learn about  the 
  389.      nodes  that the other TNCs can hear. Also, nodes heard by one  TNC  can 
  390.      take an hour to be notified to the others.
  391.  
  392.      In  order  to improve this, this parameter may be used  to  change  the 
  393.      frequency  of  nodes broadcasts on the RS232 port. When set to  0,  the 
  394.      node  operates  as  normal.  When set to a  non  zero  value,  it  will 
  395.      broadcast  the nodes on the RS232 port at that interval. Hence  setting 
  396.      it to 600 would cause nodes broadcasts at 10 minute periods. The  nodes 
  397.      broadcasts  on the radio port will continue to occur at the basic  rate 
  398.      set by the PARMS setting. The obsolescence count will be decremented at 
  399.      the basic rate, not at the faster RS232 rate.
  400.  
  401. 3.5.8 Node broadcast algorithm
  402.  
  403.      This value controls the algorithm used. Bits within the value set  have 
  404.      significance as shown below.
  405.      There  is a problem with the nodes broadcast algorithm when  many  TNCs 
  406.      are  crosslinked on RS232. In order to address this a variation to  the 
  407.      algorithm  has been implemented for experimental purposes. Feedback  on 
  408.      its use is requested. Bit zero affects the HDLC port and bit 1  affects 
  409.      the RS232 port. When a bit is set to 1, the node broadcast algorithm is 
  410.      modified so that it will not rebroadcast on the same port a node  heard 
  411.      on that port when the best quality neighbour is on that port. It  makes 
  412.      little  sense  to  use it on the HDLC port but what  the  heck,  it  is 
  413.      implemented  for  completeness. The only settings therefore  that  make 
  414.      sense  are 0 and 2. These correspond to 'normal' and 'modified  on  the 
  415.      RS232  port'  respectively. Setting it to 1 or 3 will  result  in  some 
  416.      pretty weird effects.
  417.  
  418. 3.5.9 Beacon period
  419.  
  420.      This  parameter  sets the beacon interval in seconds. In  TheNet  1.01, 
  421.      this  was  fixed at 10 minutes ( 600 seconds ). In this  version,  this 
  422.      parameter may be used to change it according the the prevailing license 
  423.      conditions.
  424.  
  425. 3.5.10 'Connect' redirector
  426.  
  427.      In  TheNet 1.01, when 'connect' is given with no destination  callsign, 
  428.      the node attempted to connect to the local host port. In a  crosslinked 
  429.      system,  this vanished down a black hole. In previous versions of  this 
  430.      code,  the  node attempted to connect to the station set  by  the  HOST 
  431.      command,  only trying the local host port if no destination was set  by 
  432.      HOST.  With this version, the node may be configured to connect to  the 
  433.      station set by the BBS, DXCLUSTER or the HOST command depending on this 
  434.      parameter.  When  zero, connect attempts will go to the  HOST  station, 
  435.      when  set to '1', it will attempt to connect to the BBS callsign.  When 
  436.      set to 2 it will attempt to connect to the DXCLUSTER callsign.
  437.  
  438. 3.5.11 'help message enable' flags
  439.  
  440.      This  word controls the sending of help messages, with each bit of  the 
  441.      word  controlling  a  separate function. Currently,  only  6  bits  are 
  442.      effective, these being as follows :
  443.  
  444.      BIT       FUNCTION
  445.      =========================
  446.      0         Whether the 'please wait, trying xxxx' operates
  447.      1         Whether all commands appear in help for sysop
  448.      2         Whether the 'goodbye' message is given
  449.      3         Whether a welcome message is enabled ( CTEXT )
  450.      4         Whether nodes are shown as 'alias:callsign'
  451.      5         If  set,  TALK data is passed as 8 bit  data  rather  than 
  452.                clearing the most significant bit
  453.      6         If set, node aliases are deemed to be case sensitive
  454.  
  455.  
  456.      When  bit 0 is set, and the BBS, HOST or DXcluster commands are  given, 
  457.      then  a message is sent from the node telling the user that  a  connect 
  458.      attempt  is  being  made. This does not affect  the  'connect'  command 
  459.      itself,  unless the command is given with no parameter as this is  then 
  460.      equivalent of the BBS or HOST command.
  461.  
  462.      When bit 1 is set, and if a sysop gives an incorrect command, the  help 
  463.      screen shows all commands possible, including those currently  disabled 
  464.      ( as by definition they are not disabled for the sysop ! ).
  465.  
  466.      When  bit  2 is set, then the use of the 'bye' command will  solicit  a 
  467.      'goodbye' message from the node.
  468.  
  469.      Bit 3 switches on and off the 'CTEXT' message. When enabled, and when a 
  470.      CTEXT message is set, then whenever someone uplinks to the node  alias, 
  471.      the ctext message is sent immediately on connect.
  472.  
  473.      Bit 4 switches the way in which nodes are shown when the ROUTES command 
  474.      is used. When set to '1', nodes are shown as 'alias:callsign'. When set 
  475.      to 0, they are shown only as 'callsign'.
  476.  
  477.      Bit  5  controls only the passing of data in TALK mode.  Normally,  all 
  478.      data  sent  to  the  node has its  most  significant  bit  cleared,  to 
  479.      eliminate  parity  or  similar problems. This is not  ideal  for  those 
  480.      countries  that use the extended character set. When this bit  is  set, 
  481.      and  only  when in TALK, data is passed as 8 bit data. Note  that  this 
  482.      does not apply to an initial message sent on the same line as the  TALK 
  483.      command.
  484.  
  485.      Bit  6  makes node handing case sensitive. Normally, node  aliases  are 
  486.      forced  to upper case for searching in the table and for user  'connect 
  487.      requests'.  If  this  bit is set, these  operations  will  become  case 
  488.      sensitive. This could be very confusing for users unless they are aware 
  489.      of  it  and expect it. It allows node aliases to be  entered  as  lower 
  490.      case,  for  example in setting the node alias and  in  forcing  routes. 
  491.      Don't set this bit unless it is actually needed !.
  492.  
  493. 3.5.12 'hash' node port control
  494.  
  495.      In  certain  networks  ( notably the American ), there  is  a  need  to 
  496.      restrict  the  propagation of local nodes. This is done by  using  node 
  497.      aliases that start with a hash character ( # ) and instructing specific 
  498.      nodes not to broadcast routes to nodes that start with this  character. 
  499.      This  parameter  does  this by enabling each port  to  be  individually 
  500.      enabled  or  disabled  in  respect to 'hash'  node  broadcasts.  Bit  0 
  501.      controls the radio port and bit 1 controls the RS232 port. When one  of 
  502.      these bits is set, hash nodes will never be broadcast on that port.
  503.  
  504. 3.5.13 Extra aliases
  505.  
  506.      If  this  is  set to '1', then the node will listen for  (  and  accept 
  507.      uplinks  to  ) the aliases set in HOSTALIAS, DXCALIAS and  BBSALIAS  if 
  508.      they  are  set. If this parameter is set to '0', or if  the  respective 
  509.      aliases are not set, it will do nothing. If you do not use the aliases, 
  510.      set it to 0 to avoid wasting processor time.
  511.  
  512. 3.5.14 Reconnect to Switch
  513.  
  514.      If this parameter is set to 0, the node operates as normally. If set to 
  515.      a non zero value ( i.e. set to '1' ), it operates in 'reconnect'  mode. 
  516.      When  a  station  connects  to the switch, then  uses  the  BBS,  HOST, 
  517.      DXCluster  or Connect commands to connect to another station, and  then 
  518.      causes   that  remote  station  to  disconnect  them,  then  they   are 
  519.      automatically reconnected to the node with a 'welcome back' message.
  520.  
  521. 3.5.15 NoSlime
  522.  
  523.      This parameter controls 'slime trails'. A 'slime trail'is caused when a 
  524.      remote node, whose identity is not known to the node, sends a transport 
  525.      connect  request  to  the node. Subject to the  settings  of  the  port 
  526.      qualities,  the  node may make an entry in the node table in  order  to 
  527.      reply to them. Such entries are typified by having no alias  associated 
  528.      with them.
  529.  
  530.      Each bit in the NoSlime parameter controls a different function. Bit 0, 
  531.      if set, causes any stations without aliases to be 'hidden' when a nodes 
  532.      command  is  given. Bit 1. if set, causes the node to  refuse  to  make 
  533.      slime trail entries in the node table. Before you use this feature,  be 
  534.      careful to make sure that you understand the implications of doing  so, 
  535.      as  without  fixed  entries  the node will refuse  to  accept  level  4 
  536.      connections from a station until it has heard their node broadcast.
  537.  
  538. 3.5.16 NoDigi
  539.  
  540.      This  parameter  controls the node's willingness to  accept  digipeated 
  541.      level  2  connections or to allow digipeated downlinks from  the  node. 
  542.      Each bit of the parameter controls a different function, as shown below 
  543.      :
  544.  
  545.      BIT FUNCTION
  546.      =======================================
  547.      0   If set, do not allow digipeated connections to the node
  548.      1   If set, do not allow digipeated downlinks from the node switch
  549.  
  550.  
  551. 3.6 MHEARD
  552.  
  553.      The  TNC  can be instructed to keep a list of the  last  'nn'  stations 
  554.      heard,  where  'nn'  is an integer between 1 and 100. It  can  also  be 
  555.      disabled. The syntax of the command is :
  556.  
  557.                MHEARD [ nn ]
  558.  
  559.      The parameter is optional and only operates for the sysop. It sets  the 
  560.      maximum length of the list. Setting to zero disables the function.
  561.  
  562.      The heard list uses free buffers for the list, so a large setting means 
  563.      less RAM for the node software.
  564.  
  565.      The  list  is maintained as linked list, with the most  recently  heard 
  566.      station first. The display shows the number of packets heard from  that 
  567.      station  and  the time since it was last heard, in  hours  minutes  and 
  568.      seconds.  In addition, it shows the port on which the station was heard 
  569.      together  with an indication as to whether the station is a node and  / 
  570.      or a TCP/IP station. It does this by examining the PID byte. 
  571.      Every  hour the list is checked for stations that have not  been  heard 
  572.      for 12 hours, and any such stations are removed from the list.
  573.  
  574.      To disable the internal updating of the list ( and thereby stop the CPU 
  575.      expending  effort on the function ), set the size to zero  rather  than 
  576.      just  disabling the command as described in 3.8. Note though  that  the 
  577.      node will not clear the list as updates have been disabled, so it  will 
  578.      be up to 12 hours before the buffers used are freed. To accelerate this 
  579.      process, set the size to 1, wait until it has heard a station ( any one 
  580.      will  do  ) then set it to zero. This will free up all but  one  buffer 
  581.      immediately.
  582.  
  583.      The  heard list is the user interface to the receive  deviation  meter. 
  584.      Its  operation  is explained in section 3.31. If enabled (  ie  if  the 
  585.      METER  parameter is not set to 0 ), then an additional column  will  be 
  586.      displayed  in the heard list that will show the received  deviation  in 
  587.      kilohertz  ( as nn.n ). It must be remembered that this is  derived  by 
  588.      measuring  the received signal audio level, and will not be correct  in 
  589.      the case of a badly distorted signal.
  590.  
  591. 3.7 CQ
  592.  
  593.      When CQ is disabled, the command now reports apologetically rather than 
  594.      simply ignoring the request.
  595.  
  596. 3.8 ALL COMMANDS
  597.  
  598.      There is often a requirement to be able to disable the connect  command 
  599.      whilst  allowing  level 3 relaying. This is achieved by the  use  of  a 
  600.      command qualifier, the syntax of which is :
  601.  
  602.                CONNECT [ + | - ]
  603.  
  604.      If '-' is entered by the sysop, then the connect command will  politely 
  605.      refuse to work. This can be reversed by the '+' command.
  606.  
  607.      This has no effect of layer 3 relaying. Also, the BBS and HOST commands 
  608.      will still allow connections to be made if they are enabled and set.
  609.  
  610.      Further,  the  syntax  is valid for ALL commands, for  example  the  CQ 
  611.      command  can also be disabled in the same way. Be careful  though.  The 
  612.      command  is only accepted from the sysop, so if you disable  the  sysop 
  613.      and manager commands you will lock out remote management !.
  614.  
  615. 3.9 NODES
  616.  
  617.      When information on a node that is not known is requested, the  program 
  618.      prints  out an error message rather than giving the names of all  known 
  619.      nodes.
  620.  
  621.      When a node entry is made by the sysop, callsign checking is forced  ON 
  622.      rather than being determined by the callsign checking parameter.
  623.  
  624.      Don't  forget  that  node alias handling may be case  sensitive  -  see 
  625.      section 3.5.11.
  626.  
  627.      The  entire  contents of the node table routes may be obtained  by  the 
  628.      sysop or manager by the command
  629.  
  630.                NODES * *
  631.  
  632.      This will dump info on all nodes, one node per line, with the following 
  633.      format:
  634.  
  635.           alias:call     route1    route2    route3
  636.  
  637.      where  route1,  route2 and route3 comprise  the  quality,  obsolescense 
  638.      count  and  port followed by the neighbour callsign for each of  the  3 
  639.      route entries for that node. If any of the routes are in use, a chevron 
  640.      will be shown by that route.
  641.  
  642.      The  extended  command is only for sysop use as it, like  auditing  and 
  643.      conferencing, causes the node to be a source of a significant amount of 
  644.      data  ( dumping a large number of node details can consume hundreds  of 
  645.      buffers  !!!  ). It is quite possible that  used  indiscriminately,  it 
  646.      could cause a warmstart of the node. Be careful.
  647.  
  648. 3.10 RESET
  649.  
  650.      The syntax of the command is now 
  651.  
  652.                RESET [ anything-else ]
  653.  
  654.      Entering  the  reset command alone will do a warmstart.  If  any  other 
  655.      parameter is entered, a coldstart is performed.
  656.  
  657. 3.11 MANAGER
  658.  
  659.      The  MANAGER command gives the user extra privileges. In this  version, 
  660.      this  amounts to the ability to receive audit messages from  the  node. 
  661.      The level of auditing is set by the AUDIT command.
  662.  
  663.      The privilege remains in force until cleared by a command that  affects 
  664.      the  user  state.  Specifically, these are, entering  the  TALK  state, 
  665.      executing  the SYSOP command, entering the MANAGER command and  getting 
  666.      the password wrong, or disconnecting from the node. Failing to get  the 
  667.      second password right when using the closedown command will also remove 
  668.      the manager privilege.
  669.  
  670.      If the MANAGER command is executed by a user who  connected to the node 
  671.      by a level 4 circuit rather than by a level 2 circuit, and if the level 
  672.      2  timeout  is less than the no activity timeout, the  connection  will 
  673.      never  timeout as the clearing and reconnecting of the level 2  circuit 
  674.      will keep the process alive provided level 2 auditing is enabled.  This 
  675.      allows   the  operation  of  the  node  to  be  logged   remotely   and 
  676.      continuously. Alternatively, if the level 4 timeout is greater than  10 
  677.      minutes,  level  1  or CPU auditing will keep it alive if  level  2  is 
  678.      switched off. NOTE : I have a nasty feeling that there is something not 
  679.      quite right here - the link sometimes dies !.
  680.  
  681.      A user with MANAGER privilege also has SYSOP privilige.
  682.  
  683. 3.12 AUDIT
  684.  
  685.      The syntax of the audit command is : 
  686.  
  687.                AUDIT [ new-value ]
  688.  
  689.      where new value is an integer value. If no value is given, or the  user 
  690.      does  not  have  SYSOP status, the current  mask  value  is  displayed. 
  691.      Otherwise, the mask is updated and the new value displayed.
  692.  
  693.      The  mask controls the auditing of various events in the node. Not  all 
  694.      values are used yet, but those that are, are :
  695.  
  696.           BIT           USE
  697.      ============================================
  698.         0      Level 1 statistics on 10 minute updates
  699.         1      Level 2 connects & disconnects
  700.         2      reserved for future use
  701.         3      Level 4 connects & disconnects
  702.         4      Level 7 limited events ( use of sysop )
  703.         5      Full level 7 auditing
  704.         6      CPU auditing messages ( 10 minute updates )
  705.  
  706.      It is suggested that the usual settings can simply be 0 or 255.
  707.  
  708.      For level 1, messages are sent every 10 minutes showing the  percentage 
  709.      of  time that the receiver detected carrier and the percentage of  time 
  710.      that the transmitter was on.
  711.  
  712.      At level 2 & 4, the messages are of all connects and disconnects, shown 
  713.      in 4 different ways :
  714.  
  715.           C   Connect message received by node
  716.           CA  Connect message sent / Acknowledge received
  717.           D   Disconnect message received by node
  718.           DA  Disconnect message sent / Acknowledge received
  719.  
  720.      In  each case, 2 callsigns are shown. At level 2 these are  the  source 
  721.      and  destination of the AX.25 link. At level 4, it is the  remote  node 
  722.      callsign  and user callsign. Each message is preceded by an  indication 
  723.      of the source of the message, such as "L2" or "L4".
  724.  
  725.      At  level 7, with bit 4 set and bit 5 clear, the only  event  currently 
  726.      audited  is  the use of the Sysop command, either directly or  via  the 
  727.      manager command. If bit 5 is set, then all commands given to the switch 
  728.      are  audited,  preceded  by the callsign of the user  who  entered  the 
  729.      command.
  730.  
  731.      Bit  6  controls CPU health check auditing. If set, then  whenever  the 
  732.      internal CPU statistics are updated, messages are sent showing the  CPU 
  733.      processor  loading total and the minimum buffers level ( see STATS  for 
  734.      more information ). 
  735.  
  736.      The  audit mask value should be set to 0 when not actually being  used. 
  737.      Do  not  leave it set to another value as this wastes  processor  time. 
  738.      Note  also that full auditing on a busy node makes things worse.  Treat 
  739.      it as a debugging feature !.
  740.  
  741. 3.13 TALK
  742.  
  743.      Talk is a conferencing command. It allows a number of stations to  hold 
  744.      a  simultaneous conference ( a bit like the CONFERENCE command of a  DX 
  745.      cluster ). There is only one conference, and stations may connect to it 
  746.      by  connecting  to  the node and issuing the TALK command.  It  may  be 
  747.      exited by disconnecting or issuing the command '/EXIT' at the start  of 
  748.      a line. ( /EXIT may be abbreviated to /EX, and it is not case sensitive 
  749.      ).
  750.  
  751.      Each  line  sent  by  a  user is copied  to  all  other  users  in  the 
  752.      conference, preceded by the callsign of the user. The data will be sent 
  753.      as  7 bit data ( ie the most significant bit will be cleared  )  unless 
  754.      the appropriate bit is set in the help flags ( see section 3.5.11 ).
  755.  
  756.      Whenever  a new station enters the conference, or a station leaves  the 
  757.      conference using the '/EXIT' command, the other conference users get  a 
  758.      message  informing  them of the event. These status messages  are  sent 
  759.      with the callsign of the node rather than the user.
  760.  
  761.      Finally,  when entering the TALK command, a message may be sent to  all 
  762.      those  users  who  are connected to the node but  not  otherwise  doing 
  763.      anything. For example if GxABC enters the line
  764.  
  765.           TALK Hello fred, can I have a chat, type 'TALK'
  766.  
  767.      Then all other stations connected to the node, present in the USER list 
  768.      but idle, get the message
  769.  
  770.           GxABC>> Hello fred, can I have a chat, type 'TALK'
  771.  
  772.      displayed on their terminal.
  773.  
  774.      Note  that  merely  connecting to the node  does  not  consitute  being 
  775.      connected to the switch. Stations connected to the switch appear in the 
  776.      USER list.
  777.  
  778. 3.14 SYSOP
  779.  
  780.      The  SYSOP command has been enhanced to increase the level of  security 
  781.      offered.  One problem of the old system is that the password is  easily 
  782.      visible  unless the user repeats the SYSOP command a number  of  times. 
  783.      Even then, correlation between passwords is easy, so the password needs 
  784.      frequent  changing. To reduce the change period, and make it harder  to 
  785.      discover,  the node will accept a string of characters and scan it  for 
  786.      the  password.  Hence a response of, say, 30 or 40  characters  can  be 
  787.      sent,  with a random number of random characters preceding  the  actual 
  788.      data  and  a random number following it. This does not  eliminate  such 
  789.      attacks,  but  if  used carefully, it makes it quite a  bit  harder  to 
  790.      attack.
  791.  
  792. 3.15 LINKS
  793.  
  794.      This command shows the current level 2 links to the node. Displayed one 
  795.      per line, the two callsigns are shown followed by the link state,  port 
  796.      number and current retry count.
  797.  
  798. 3.16 CALIBRATE
  799.  
  800.      This  command  allows  remote calibration  checks  of  the  transmitter 
  801.      deviation. Its syntax is
  802.  
  803.           CALIBRATE period [ toggle ]
  804.  
  805.      The  period ( 1 to 60 seconds ), is the time for which the  transmitter 
  806.      will  key up for with constant tone. It is undefined as to  which  tone 
  807.      will  be sent. If the second parameter is given, the node  will  toggle 
  808.      between the tones every [toggle] seconds. The toggle must be between  1 
  809.      and  [period] seconds. If a period is not given, the user is not  sysop 
  810.      or  manager, or if it is out of range, the command is ignored.  If  the 
  811.      tone  generator is busy because it is about to send a CWID sequence,  a 
  812.      'busy'  message is returned. Note - quite often it can appear that  the 
  813.      node has locked up having failed to transmit the full calibrate period. 
  814.      In fact, this is usually the hardware PTT watchdog in the TNC. The node 
  815.      thinks  it is still sending but the hardware timer has removed the  PTT 
  816.      signal.
  817.  
  818. 3.17 DXCLUSTER
  819.  
  820.      The DXCLUSTER command operates just like the BBS command in that it may 
  821.      be  used to effect a connection to a DXcluster (assuming there  is  one 
  822.      nearby).  It  should be disabled if it is not intended to  be  used  to 
  823.      access a cluster.
  824.  
  825.      The syntax of the command is :
  826.  
  827.                DXCLUSTER [ * | ? | callsign ]
  828.  
  829.      With  no  parameter,  the  command connects  to  a  station  previously 
  830.      specified  by  the use of the DXCLUSTER command with a  callsign  as  a 
  831.      second parameter. Setting the DXCLUSTER to allow this may only be  done 
  832.      by a sysop. The '*' option may also only be executed by the sysop, this 
  833.      command clears a previously specified DXCLUSTER.
  834.  
  835.      The  '?'  option ( or any text if not sysop ), prints out  the  current 
  836.      DXCLUSTER station setting.
  837.  
  838.      If  no DXCLUSTER is set, the command issues an error message if  it  is 
  839.      invoked with no other parameters.
  840.  
  841.      The  idea of this command is that, like with the 'bbs' command  of  the 
  842.      'BPQ software, a user may connect to the local DXCLUSTER from the node.
  843.  
  844. 3.18 HELP
  845.  
  846.      The  HELP  command  gives a message from the ROM.  In  general,  it  is 
  847.      expected  that  the  message will be designed to assist  new  users  in 
  848.      understanding  the operation or configuration of the node. The  message 
  849.      may span many lines, and may be changed when the ROM is programmed.  As 
  850.      delivered, it contains a brief help screen detailing the main ( user  ) 
  851.      changes to the code.
  852.  
  853. 3.19 CTEXT
  854.  
  855.      The  CTEXT  command  sets  or displays a message sent  to  a  user  who 
  856.      connects to the node by uplinking to the node's alias.
  857.  
  858.      The syntax of the command is :
  859.  
  860.           CTEXT [ * | message ]
  861.  
  862.      With  no  parameter, the current message is displayed. If the  user  is 
  863.      also  a sysop, and if text follows the command, that text is  added  to 
  864.      the current connect text. If the message starts with a '*', the connect 
  865.      text message is deleted. Hence, to clear the message, type the  command 
  866.      'ctext *'. This is change a in version X-1J from previous versions. For 
  867.      further information, see section 3.33
  868.  
  869.      A  message  is  only sent if there is a ctext message set  and  if  the 
  870.      relevant  bit is set in the mode command parameter as described in 
  871.      section 3.5.11.
  872.  
  873. 3.20 BTEXT
  874.  
  875.      The  BTEXT  command sets or displays the additional  beacon  text  sent 
  876.      along with the beacon packets.
  877.  
  878.      The syntax of the command is :
  879.  
  880.           BTEXT [ * | message ]
  881.  
  882.      With  no  parameter, the current message is displayed. If the  user  is 
  883.      also  a sysop, and if text follows the command, that text is  added  to 
  884.      the  current beacon text. If the message starts with a '*', the  beacon 
  885.      text message is deleted. Hence, to clear the message, type the  command 
  886.      'btext *'. This is change a in version X-1J from previous versions. For 
  887.      further information, see section 3.33
  888.  
  889.      Normally,  beacon packets are UI frames that contain the node  callsign 
  890.      and alias. If a beacon message is set, the text of the message  follows 
  891.      the  alias  in the same packet. It is strongly  suggested  that  beacon 
  892.      packets be kept brief !!!.
  893.  
  894. 3.21 ACL
  895.  
  896.      This is probably the most complex additonal command in the program.  It 
  897.      should  be  used  with care, and only when you  really  understand  its 
  898.      operation - mistakes can result in the need to go out to a remote  site 
  899.      ( probably when it is cold and wet ) to reconfigure the node.
  900.  
  901.      The  command allows selective control, based on callsign, of a list  of 
  902.      different events. The ACL contains two types of entry, a default  value 
  903.      and zero or more callsigns, each of which are associated with a  value. 
  904.      When one of the controlled events occurs ( such as an incoming level  2 
  905.      connection or a nodes broadcast ), the ACL is scanned for an entry that 
  906.      matches the callsign of the sender. If a match is found ( but see below 
  907.      ),  the  value associated with that callsign is used to  determine  the 
  908.      action  the node will take. If no match is found, the default value  is 
  909.      used.
  910.  
  911.      Each bit of the value controls a different function, as shown below :
  912.  
  913.           BIT      OPERATION
  914.           =====================================================
  915.           0    bar incoming level 2 connection
  916.           1    bar outgoing level 2 connection ( downlink )
  917.           2    ignore nodes broadcasts from this station
  918.           3    bar gatewaying at level 3 to/from this station
  919.           4    bar incoming level 4 connections
  920.           5    bar outgoing level 4 connections
  921.           6    ignore SSID in matching an entry
  922.  
  923.      So if for example an entry exists for a callsign G99XXX of 6, then  the 
  924.      node  will  not  allow  outgoing level 2  connections  to  the  node  ( 
  925.      downlinks  ), and will ignore node broadcasts from that  station.  Note 
  926.      that  these commands only operate on the events themselves - if  G99XXX 
  927.      creates  a  level  2 connection, the node will  quite  happily  use  it 
  928.      itself.
  929.  
  930.      The 'ignore ssid' bit is used to match a callsign without regard to its 
  931.      SSID. This makes life interesting when finding a match, so the list  is 
  932.      scanned  twice, once for an exact match, and then for a match  ignoring 
  933.      SSID if an exact match is not found. There can only be one exact match, 
  934.      but  when  searching for a match without using SSID,  the  first  entry 
  935.      found will be used.
  936.  
  937.      The syntax of the command is as follows ( 3 versions )
  938.  
  939.           ACL * value
  940.           ACL callsign + value
  941.           ACL callsign -
  942.  
  943.      If  you  are  not sysop, or if ACL is given on  its  own,  the  current 
  944.      contents  of the ACL are shown. The first form of the  command  changes 
  945.      the default value, the second form makes an entry in the list, the last 
  946.      form removes an entry from the list. It complains about syntax errors.
  947.  
  948.      A few moments thought will show that the sequence of commands
  949.  
  950.           connect to node
  951.           execute sysop or manager command
  952.           type the command ACL * 127
  953.           disconnect
  954.  
  955.      is quite catastrophic. You will not be able to get back in again  apart 
  956.      from via the host port and noone will be able to connect to or from the 
  957.      node. If you intend to experiment with the command, you should start by 
  958.      entering your own callsign with a value of zero to ensure that you  can 
  959.      get back in again !!!.
  960.  
  961.      The  list can be used as an 'accept' or 'reject' list by judicious  use 
  962.      of the default. To create a list that excludes specific calls, put them 
  963.      into  the  list with the required bits set in the  value.  The  default 
  964.      should  be  zero. To create an 'accept' list, put entries in  with  the 
  965.      required  bits  zero  and set the corresponding bits  in  the  default. 
  966.      Individual  bits may be used to create accept or reject lists for  each 
  967.      function.
  968.  
  969.      The command steals buffers at a rate of one buffer per four entries  in 
  970.      the  ACL.  Also, a long ACL will slow the node down nicely -  so  think 
  971.      before you enter a long list.
  972.  
  973.      This  command is for experimental purposes - if you find any bugs,  let 
  974.      me know please ( I have not fully tested the gateway bit for example ). 
  975.      Also, it is not intended for malicious use but to allow fine control to 
  976.      be  exercised  over  backbone  networks. If  I  get  lots  of  negative 
  977.      responses back, the command will go !
  978.  
  979. 3.22 CLOSEDOWN
  980.  
  981.      The  closedown  command  is used to shut down  the  node  remotely.  If 
  982.      successfully  executed, the node will effectively stop operating  until 
  983.      it  is reset ( eg by a power up ). The node's configuration  (  routes, 
  984.      messages  etc  )  are  not destroyed - the  node  simply  hits  a  HALT 
  985.      instruction. You must be sysop to execute the command.
  986.  
  987.      The syntax of the command is:
  988.  
  989.                CLOSEDOWN A
  990.  
  991.      The  node  will respond with 5 numbers just as for when  the  sysop  or 
  992.      manager  command  was  executed. Yes, you  guessed,  the  node  expects 
  993.      another   password.  Give  it  correctly  and  the  node  closes   down 
  994.      completely.  Get it wrong and you lose your sysop status.  This  obtuse 
  995.      and  awkward  syntax is designed to make sure it  is  not  accidentally 
  996.      executed.
  997.  
  998. 3.23 ALIAS
  999.  
  1000.      The ALIAS command allows the node's alias to be changed. The syntax  is 
  1001.      :
  1002.  
  1003.           ALIAS [ * | new-alias ]
  1004.  
  1005.      If  no parameter is given, or if the user is not SYSOP or MANAGER,  the 
  1006.      current alias is displayed. If the alias is deemed to be a valid alias, 
  1007.      the  node's  alias  is changed to the new one entered.  Note  that  the 
  1008.      algorithm  that  checks for the alias structure is a bit queer.  It  is 
  1009.      however,  the original algorithm of TheNet and I am loth to  change  it 
  1010.      for fear of side effects. Note too that the companion CALLSIGN  command 
  1011.      is  NOT included - chaos is not something I crave. If the  sysop  gives 
  1012.      the parameter of '*', the node's alias is cleared.
  1013.  
  1014. 3.24 BBSALIAS HOSTALIAS DXCALIAS
  1015.  
  1016.      These  commands are used to enable the node to respond to up  to  three 
  1017.      additional  aliases.  The  syntax of each is the same, and  by  way  of 
  1018.      example the BBSALIAS syntax is :
  1019.  
  1020.           BBSALIAS [ * | new-alias ]
  1021.  
  1022.      If not sysop, if no new alias is specified, or if it does not pass  the 
  1023.      weird  alias  syntax  checker ( see 3.23 ) then the  current  alias  is 
  1024.      displayed. If not, the alias is changed. If '*' is given, the alias  is 
  1025.      cleared.
  1026.  
  1027.      The aliases so entered are nothing to do with the node's identity. If a 
  1028.      BBS alias is set, for example to MXMBBS, then the node will listen  for 
  1029.      level  2  connects  to that alias. It will respond  to  them  and  will 
  1030.      automatically  invoke  the  BBS  command. The use  will  also  get  the 
  1031.      optional  welcome  (ctext)  message and 'trying  to  connect  to  ....' 
  1032.      messages if enabled by the appropriate 'mode' parameter.
  1033.  
  1034.      The  idea  is that where a node sits on a channel that  does  not  have 
  1035.      access  to the local host, BBS or cluster, the normal aliases of  those 
  1036.      stations  may be enabled in the node to allow consistent access to  the 
  1037.      local  services. Note that the three stations do not have to be a  BBS, 
  1038.      Host and cluster, it could be three BBSes or any other combination.
  1039.  
  1040. 3.25 IPSTATS
  1041.  
  1042.      The  IPstats  command has the same basic syntax as the PARMS  and  MODE 
  1043.      commands.  When  invoked without parameters, it  displays  the  current 
  1044.      stats.  Each  statistic  may also be altered by sysop,  as  defined  in 
  1045.      section 3.32.
  1046.  
  1047.      In  addition to the standard IP MIB, there is an  additional  parameter 
  1048.      used  to set the level 2 default modes, and the first entry in the  MIB 
  1049.      is used to enable or disable the router.
  1050.  
  1051.      The  complete set of IP MIB stats are included for  compatibility  with 
  1052.      other IP systems, but several are not used. Also, the stats are 16  bit 
  1053.      counters not 32 bit counters as in NOS. Like NOS however, the stats  do 
  1054.      not  reset  every hour, they must be cleared by the  sysop.  They  will 
  1055.      however wrap around at zero.
  1056.  
  1057.      The entries are:
  1058.  
  1059.      1    Port default modes
  1060.      2    Enable / Disable the IP router fuctions
  1061.      3    Default IP Time To Live
  1062.      4    IP Received frames
  1063.      5    IP Header Errors
  1064.      6    IP Input Address Errors
  1065.      7    IP Forwarded Datagrams
  1066.      8    IP Unknown Protocols
  1067.      9    IP input frames Discarded
  1068.      10   IP Input frames Delivered
  1069.      11   IP Output Requests
  1070.      12   IP Output Discards 
  1071.      13   IP Output No Routes errors
  1072.      14   IP Reassembly Timeout errors
  1073.      15   IP Reassembly Required errors
  1074.      16   IP Reassembly OKs
  1075.      17   IP Reassembly Fails
  1076.      18   IP Fragmentations completed OK
  1077.      19   IP Fragmentation Failures
  1078.      20   IP Fragmentation Creates
  1079.  
  1080.      The  default mode word may be set to 0, 1, 2 or 3. Each bit controls  a 
  1081.      port, with bit 0 controlling port 0 ( radio port) and bit 1 controlling 
  1082.      port  1 ( RS232 port ). When set to 1, the default mode for  that  port 
  1083.      when sending on a level 2 connection will be Datagram. When set to 0 it 
  1084.      will  be  by Virtual Circuit. The default mode is used  when  no  other 
  1085.      information is given, either by the ARP table or by the TOS bits in the 
  1086.      IP header.
  1087.  
  1088.      The  enable  / disable word may be set to 0 or 1. When set  to  0,  the 
  1089.      operation of the router is stopped, when set to 1 the router functions.
  1090.  
  1091.      The  IP Time To Live ( TTL ) word is used to set the number of  routers 
  1092.      through  which  an  IP frame may pass before it  is  discarded.  It  is 
  1093.      similar to the node layer 3 TTL word. It may be set to any value up  to 
  1094.      255, but values below 2 make no sense and are therefore not permitted.
  1095.  
  1096.      The IP fragmentation reassembly timeout counter is not used as the node 
  1097.      is  just a router. It is left set to 30 seconds just to show which  one 
  1098.      it is !
  1099.  
  1100.      The  rest are just statistics. The patient user can have hours  of  fun 
  1101.      working  out  which ones are not used ( or just think about  it  for  a 
  1102.      second or two ).
  1103.  
  1104. 3.26 IPADDRESS & IPBROADCAST
  1105.  
  1106.      These commands are used to set or display the IP addresses used by  the 
  1107.      node. The syntax of each is (by way of example):
  1108.  
  1109.           IPADDRESS [ ipaddress ]
  1110.  
  1111.      where ipaddress is in the form 
  1112.  
  1113.           nnn.nnn.nnn.nnn 
  1114.  
  1115.      where nnn is an integer in the range 0..255
  1116.  
  1117.      So  to  set the node IP broadcast address to that used over  here,  the 
  1118.      command would be :
  1119.  
  1120.           IPBROADCAST 44.131.0.0
  1121.  
  1122.      The IPADDRESS is the address that the node will respond to. It is  used 
  1123.      only as detailed in section 7. The IP broadcast address is the one used 
  1124.      to  denote  broadcast packets that will be largely ignored.  Note  that 
  1125.      port  addressing  is  NOT currently supported. Anyone  who  finds  this 
  1126.      limiting, drop me a line and I'll see if I can change it.
  1127.  
  1128. 3.27 IPROUTE
  1129.  
  1130.      This  is one of the two main databases used by the node. The  IP  Route 
  1131.      table  is used to tell the router where to send a frame for a  specific 
  1132.      detination. It maps addresses or address ranges to a gateway IP address 
  1133.      and  to  sub-network ports. The ARP database then tells the  node  what 
  1134.      station corresponds to that address and protocol. The node supports two 
  1135.      subnet protocols, AX25 and Net/Rom.
  1136.  
  1137.      The  database is stored in an ordered list, in decreasing order of  the 
  1138.      number  of relevant bits. This is to permit searching of  the  database 
  1139.      when trying to find a specific destination. Given an address, it  scans 
  1140.      addresses  with decreasing numbers of bits until it finds a match.  The 
  1141.      syntax of the command is as follows :
  1142.  
  1143.           IPROUTE [address [ / bits ][ + port [gateway [metric]]]]
  1144.  
  1145.      or
  1146.  
  1147.           IPROUTE [address [ / bits ][ - ]]
  1148.  
  1149.      In  the  first form, it makes an entry in the table, in the  second  it 
  1150.      deletes  one.  Only  sysop or manager may effect  such  a  change.  The 
  1151.      parameters are as follows :
  1152.  
  1153.      address       The amprnet address in the form nnn.nnn.nnn.nnn
  1154.      bits          The number of significant bits (eg 44.131.0.0 / 16)
  1155.      port          The port, either 0 or 1 for AX25 or n for Net/Rom
  1156.      gateway       The optional gateway for this dest. nnn.nnn.nnn.nnn
  1157.      metric        Currently not used, a numeric value
  1158.  
  1159.      When  an entry is made with a specific number of bits, the  address  is 
  1160.      'masked  off' to that many bits, so enter an address of 44.131.16.31  / 
  1161.      24  and  it will get entered as 44.131.16.0. The valid  range  for  the 
  1162.      number of bits is 1 - 32.
  1163.  
  1164.  
  1165. 3.28 ARP
  1166.  
  1167.      The   ARP   table   maps   a   pair   of   address+port   to   hardware 
  1168.      address+subnetwork  mode.  The  address is either a  destination  or  a 
  1169.      gateway in the form nnn.nnn.nnn.nnn. The protocol is either Net/Rom  or 
  1170.      ax25. The hardware_address is a callsign and the subnetwork mode is  DG 
  1171.      or VC ( only has significance for level 2 links ).
  1172.  
  1173.      The syntax of the command is :
  1174.  
  1175.               ARP [ destination [ + [ P ] protocol callsign [ mode ] ] ]
  1176.  
  1177.      or
  1178.  
  1179.              ARP [ destination [ - protocol ] ]
  1180.  
  1181.      In the first form an entry is made in the table, in the second an entry 
  1182.      is deleted. This is only permitted for sysop or manager.
  1183.  
  1184.      The parameters are :
  1185.  
  1186.      destination   An address of the form nnn.nnn.nnn.nnn
  1187.      P             If present, marks the entry as 'published'
  1188.      protocol      AX25 or Net/Rom
  1189.      callsign      A valid amateur callsign, e.g. G8KBB-5
  1190.      mode          DG or VC
  1191.  
  1192.      If   'P'  is  entered,  then  the  node  will  publish   the   address. 
  1193.      Specifically, if an ARP request is seen by the node for a station  with 
  1194.      the  address given, it will send a response advising the caller of  the 
  1195.      callsign to be used.
  1196.  
  1197.      More details on the operation of the router are contained in section 7.
  1198.  
  1199. 3.29 UI
  1200.  
  1201.      The  UI command allows a string to be sent as a Level 2 UI  frame.  The 
  1202.      syntax is
  1203.  
  1204.           UI dest string_of_text_ending_in_return
  1205.  
  1206.      Dest is a callsign like destination such as 'MAIL'. What will happen is 
  1207.      that a single UI frame will be sent with a source callsign of the  user 
  1208.      who entered the command,a destination callsign of dest, and the rest of 
  1209.      the string as text.
  1210.  
  1211.      It is designed to be used in situations where a local BBS does not have 
  1212.      access  to  a  common  channel and wishes  to  send  mail  notification 
  1213.      packets. Not surprisingly, the ability to do this is BBS specific.
  1214.  
  1215. 3.30 MTU command
  1216.  
  1217.      The  MTU command is used to confugure the node's  Maximum  Transmission 
  1218.      Unit figures ( primarily for TCP/IP support ). In general, they  should 
  1219.      be  left at the default values. Do not experiment unless you  are  sure 
  1220.      you understand the significance of what you are doing !!!!
  1221.  
  1222.      The  syntax of the command is identical to the syntax of the PARMS  and 
  1223.      MODE commands, as defined in section 3.32.
  1224.  
  1225.      There are 5 values configured by the command. These are :
  1226.  
  1227.      Number  Default   Function
  1228.      ==================================================================
  1229.      1         256  Sets MTU for IP router, AX.25 L2, Radio port (port 0)
  1230.      2         256  Sets MTU for IP router, AX.25 L2, RS232 port ( port 1 )
  1231.      3         236  Sets the MTU for the IP router Net/Rom interface
  1232.      4         257  Sets  the maximum number of data bytes permitted  in  an 
  1233.                     AX.25 level 2 frame before an error response is returned 
  1234.                     to the sender ( frame too long )
  1235.      5         328  Sets the maximum number of bytes permitted in a level  2 
  1236.                     packet.  Above this, frames are discarded. If  a  packet 
  1237.                     may contain 256 data bytes, and a maximum length address 
  1238.                     of sender, recipient and 8 digis comprises 70 bytes, and 
  1239.                     2 bytes are used for control bits, the total (  256+70+2 
  1240.                     ) is the setting of this parameter.
  1241.  
  1242.      This command replaces the ROM patching needed for TheNet X-1H.
  1243.  
  1244.      The  minimum that an MTU may be set to is 64, the maximum is 1024,  but 
  1245.      large  packets  increase the probability of crashing the  node.  Beware 
  1246.      !!!!!!.
  1247.  
  1248.      The  MTU for the Net/Rom port should not in general be set higher  than 
  1249.      236 or it will not be compatible with Net/Rom.
  1250.  
  1251.      The  limits on the other two correspond to those necessary  to  support 
  1252.      frames in the range 256 - 1024 data bytes long.
  1253.  
  1254. 3.31 METER command
  1255.  
  1256.      The Meter command is used to control the ADC functions of the software. 
  1257.      In  this  version, this is limited to the Deviation meter,  but  future 
  1258.      releases  may  extend  this, for example to configure  a  signal  level 
  1259.      meter.
  1260.  
  1261.      The syntax is as for the PARMS and MODE commands, as defined in section 
  1262.      3.32. It currently has only one parameter.
  1263.  
  1264.      When set to 0, the deviation meter is disabled.
  1265.  
  1266.      When set to a value in the range 1 - 255, the meter is enabled and  the 
  1267.      value  is used as a scaling factor. The ADC is an 8 bit device,  so  it 
  1268.      will  give  a response in the range 0 - 255, corresponding  to  an  ADC 
  1269.      input  voltage  in the range 0 - 3 volts DC. If  optimally  configured, 
  1270.      this  corresponds  to the maximum audio level possible  for  the  given 
  1271.      receiver discriminator.
  1272.  
  1273.      The ADC reading ( 0 - 255 ) is multiplied by the meter parameter  value 
  1274.      ( 1 - 255 ) to give an answer in the range 0 to 65 KHz ( approx ). This 
  1275.      is the value displayed in the mheard list.
  1276.  
  1277.      Hence, if, for example, a DC voltage of 2 volts at the input to the ADC 
  1278.      corresponds  to 3.4 KHz deviation, the ADC reading will be 171 (  +-  a 
  1279.      few  ) and the Meter parameter will need setting to 20 ( ie to  3400  / 
  1280.      171 ).
  1281.  
  1282.      If  the  ADC  reading is 254 or higher, then in order  to  indicate  an 
  1283.      overrange,  the  symbol  '>'  will precede the corresponding  deviation
  1284.      entry in  the heard list.
  1285.  
  1286. 3.32 PARM, MODE, MTU, METER & IPSTATS command syntax
  1287.  
  1288.      The syntax of these commands has changed.
  1289.  
  1290.      All use the same syntax, which may be either of two types, the original 
  1291.      TheNet  1.01  syntax  ( as used in versions previous to X-1J  )  or  an 
  1292.      'offset & value' type.
  1293.  
  1294.      The original syntax was, by way of example, 
  1295.  
  1296.               PARM { [ * | new_value ] [ * | new_value ] .......... }
  1297.  
  1298.      so to set the 10th PARM ( the L4 retries ) to 1, the syntax would be :
  1299.  
  1300.               PARM * * * * * * * * * 1
  1301.  
  1302.      The equivalent new syntax command would be :
  1303.  
  1304.               PARM / 10 1
  1305.  
  1306.      The  '/'  command signifies that what follows is the  parameter  number 
  1307.      followed by the new value. As for the old command syntax, the  complete 
  1308.      list  of  parameters is displayed. Setting the parameters may  only  be 
  1309.      done  by a Sysop. Note that BOTH command syntaxes are supported  -  you 
  1310.      can use whichever you prefer.
  1311.  
  1312. 3.33 BTEXT, INFO and CTEXT Command Syntax
  1313.  
  1314.      In Version X-1J, the syntax of these commands changed. In addition, the 
  1315.      Info message was doubled in size to 160 bytes.
  1316.  
  1317.      If someone who is not Sysop uses the command, the current settings  are 
  1318.      displayed.
  1319.      If  a  Sysop  uses it without any additional  parameters,  the  current 
  1320.      setting is displayed.
  1321.      If  a Sysop enters one of the commands followed by a parameter of  '*', 
  1322.      the current message is deleted.
  1323.      If  a Sysop enters a string of text, that text is added to the  current 
  1324.      message, followed by a newline.
  1325.  
  1326.      It  is  therefore possible to build up multiple line messages.  If  you 
  1327.      wish  to start a message with a blank line, enter a message with a  non 
  1328.      display  ( or innocuous display ) character such as control-A. It  will 
  1329.      get  entered  followed  by a newline. On most  systems  this  will  not 
  1330.      display. On some systems such as PCs running NOS, it will display as  a 
  1331.      smiley face.
  1332.  
  1333. 4. Other Changes
  1334.  
  1335.      This section covers the other miscellaneous changes to the software.
  1336.  
  1337. 4.1 Command Processor
  1338.  
  1339.      The  command  processor has been altered. In general, but  not  in  all 
  1340.      cases,  commands only appear on the 'help' menu when they are  enabled, 
  1341.      so  for example the 'BBS' command will not be shown unless it has  been 
  1342.      enabled with the 'BBS +' command. The exception is the sysop  commands, 
  1343.      like  MODE, LINKS and PARMS, which are never shown to users but are  of 
  1344.      interest  to  them. If the appropriate bit is set however in  the  MODE 
  1345.      command  (  see 3.5.11 ), then for the sysop or manager,  all  commands 
  1346.      appear in the help prompt - EVEN IF DISABLED.
  1347.  
  1348.      The help screen now shows commands in a combination of upper and  lower 
  1349.      case characters.
  1350.  
  1351. 4.2 Beacon digi
  1352.  
  1353.      It  is possible to set a digi in the address used for  beacon  packets. 
  1354.      Details  of  how to do this are contained in the  configuration  guide. 
  1355.      Note  that  this is provided for those rare occasions when there  is  a 
  1356.      genuine  need.  This is rarely the case and should not be  done  unless 
  1357.      really necessary.
  1358.  
  1359. 4.3 Nodes Broadcasts after power-up
  1360.  
  1361.      The  node will now broadcast its node table 60 seconds after  power-up. 
  1362.      This  is to ensure that the network is back to an operational state  as 
  1363.      soon as possible following a node reset. The reason for the short delay 
  1364.      is  to  cater for the situation where the Sysop switches  on  the  node 
  1365.      before the radio.
  1366.  
  1367. 5. CWID keyer.
  1368.  
  1369.      The CWID keyer sends the station callsign in CW by alternating  between 
  1370.      the  two  modem tones. This is nominally sent at 20 wpm once  every  30 
  1371.      minutes, but the speed and period can be changed remotely. 
  1372.  
  1373.      After  a delay of 30 minutes, the callsign is sent appended to the  end 
  1374.      of  the next data packet that is sent over the air. There is a  500  ms 
  1375.      delay after the end of the data packet before the call is sent.
  1376.  
  1377.      The  program prefers to send CWIDs appended to ordinary  data  packets. 
  1378.      However,  if  one minute after the CWID has supposed to be sent  it  is 
  1379.      still  pending because no data packets have been sent, it will  key  up 
  1380.      the  transmitter  anyway.  Persist, TxDelay and  other  parameters  are 
  1381.      honored,  but the process involves changing the SIO mode and this  will 
  1382.      have  an  annoying effect on any packets being received in  full duplex 
  1383.      mode.
  1384.  
  1385.  
  1386. 6. Version X-2.
  1387.  
  1388.      X-1  was the first release of this code. The objective is to  get  some 
  1389.      practical  feedback and test the code before the full release,  version 
  1390.      X-2, which I hope will be very similar to this release ( X-1J ). I have 
  1391.      been saying this for some time now, but things keep getting added.  The 
  1392.      next  version  will hopefully be a significant change  with  extensions 
  1393.      from G8AMD, but this may be some time off yet...
  1394.  
  1395.      Version X-1A added the escape-N command and the change to the  connect, 
  1396.      nodes  and  reset  commands. The timers were also added  to  the  stats 
  1397.      command.
  1398.  
  1399.      Version  X-1B removed all the escape commands apart from C,D and P.  It 
  1400.      also added the MODE command and extended the + and - command qualifiers 
  1401.      to all commands.
  1402.  
  1403.      Version  X-1C  added  TALK, MANAGER and AUDIT. The  SYSOP  command  was 
  1404.      enhanced  and  the INFO command was altered to limit the  length  of  a 
  1405.      message  ( a bug in the original version of TheNet ). The  help  screen 
  1406.      was  changed  to display commands in a combination of upper  and  lower 
  1407.      case.
  1408.  
  1409.      Version  X-1D  extended the auditing and statistics to  cover  auditing 
  1410.      everything but level 3, and statistics of the CPU, Level 1, Level 2 and 
  1411.      timers.
  1412.  
  1413.      Version  X-1E added beacon timer control, the connect  redirector,  the 
  1414.      nodes dump facility, level 3 & 4 statistics and the LINKS and CALIBRATE 
  1415.      commands.
  1416.  
  1417.      Version X-1F added the CLOSEDOWN, DXCLUSTER, ACL, CTEXT, HELP and BTEXT 
  1418.      commands.  Another parameter was added to the MODE command  to  control 
  1419.      textual messages. The mod suggested by DF2AU to correct the DCD latchup 
  1420.      was  included.  Additional statistics were added covering  CRC  errors, 
  1421.      receiver overrun, transmitter underrun and framing errors.
  1422.  
  1423.      Version X-1G added mainly the IP router, with the following commands to 
  1424.      control  it  -  IPROUTE,  ARP,  IPSTATS,  IPADDRESS,  IPBROADCAST.   In 
  1425.      addition,  the ALIAS, BBSALIAS, HOSTALIAS and DXCALIAS  commands  crept 
  1426.      in, as did QUIT as an alternative to BYE. The help messages extended to 
  1427.      enable  nodes  in the routes list to appear as alias:callsign,  and  an 
  1428.      extra byte on the MODE command allowed '#' nodes to be selectively  NOT 
  1429.      broadcast.  The order of HELP and HOST commands changed so that 'h'  on 
  1430.      its  own  gave  help not host. The code was optimised  with  some  time 
  1431.      critical  parts  being recoded in assembler and  a  peephole  optimiser 
  1432.      being used for additonal improvements.
  1433.  
  1434.      Version X-1H fixed 3 bugs in X-1G.
  1435.  
  1436.      Version  X-1J added the deviation meter support with the Meter  command 
  1437.      and  Mheard  changes. In addition, parameters were added  to  the  MODE 
  1438.      command   for   slime  trail  control,  control  of   digipeating   and 
  1439.      reconnection  to node. The command syntax of Info, Btext and Ctext  was 
  1440.      changed  to  support  multiple lines and the  Info  message  space  was 
  1441.      doubled to 160 bytes. Nodes broadcasts now occur 60 seconds after power 
  1442.      up  and the ARP Digi bug fix was included. The level 4 minimum  retries 
  1443.      was  dropped  to 1 and the PARM, MODE, IPSTATS, METER and  MTU  command 
  1444.      syntax was extended to support 'offset & value' type operation. An  MTU 
  1445.      command  was added to allow IP MTU limits to be changed under  software 
  1446.      control.  The  node alias case sentivity bit and TALK 8 bit  data  bits 
  1447.      were added.
  1448.  
  1449.      If  you  read  this and say 'Pah. it doesn't do  XXXXX'  or  'It  still 
  1450.      doesn't  do  YYYYY' or anything of a similar nature, don't keep  it  to 
  1451.      yourself.  Tell me. I may well do it. An example of this are  the  many 
  1452.      changes  introduced  into  X1-J as a result of  suggestions  mainly  by 
  1453.      KA2DEW.
  1454.  
  1455. 7. The IP router
  1456.  
  1457.      The  IP  router co-exists in the node with the other  software.  It  is 
  1458.      connected  to the L2 and L3(Net/Rom) protocol machines, and is  managed 
  1459.      from  the L7 switch. It will accept data from L2 Datagrams, L2  Virtual 
  1460.      Circuits  or  NOS protocol extended Net/Rom frames. It will  output  to 
  1461.      these 3 depending on the setting of the IProute and ARP tables.
  1462.  
  1463.      The   router  supports  the  IP  options  of  NOS  and  also  does   IP 
  1464.      fragmentation. Level 2 segmentation is not supported. In addition, ICMP 
  1465.      is implemented in so far as it is needed to respond to errors or PINGs. 
  1466.      No  higher  layer  support is provided, i.e. TCP  is  not  implemented, 
  1467.      ip_send()  and ip_receive() are only implemented in so far as they  are 
  1468.      needed  for  ICMP.  You can therefore PING it but  anything  else  will 
  1469.      solicit an ICMP error message.
  1470.  
  1471.      It will respond to ARP & REV_ARP requests but will never initiate them. 
  1472.      The  default MTU is 256 for AX.25 and 236 for Net/Rom. It  will  accept 
  1473.      longer  datagrams  than  this and fragment the output  but  it  is  not 
  1474.      recommended  as  it merely wastes RAM. The MTU command may be  used  to 
  1475.      change this.
  1476.  
  1477.      It  is  possible to be creative in the use of L2 datagram  and  virtual 
  1478.      circuits  by  use of the port default settings and the ARP  table.  The 
  1479.      algorithm used is :
  1480.  
  1481.           When  a  frame  is to be sent, the ARP table is  scanned  for  the 
  1482.           appropriate  entry. The entry tells it what callsign to  use.  For 
  1483.           Net/Rom encapsulation, it is send to the Net/Rom protocol handler. 
  1484.           For  AX.25 encapsulation the following applies. The ARP table  may 
  1485.           indicate  DG or VC. In this case, that mode is taken. If there  is 
  1486.           no DG or VC entry, the TOS bits are examined. If the delay bit  is 
  1487.           set, a datagram mode is selected. If not, and the reliability  bit 
  1488.           is  set a virtual circuit is selected. If neither bit is set,  the 
  1489.           default mode for that port is used to select a mode ( see  IPstats 
  1490.           command, first parameter ).
  1491.  
  1492.      Port addressing is not supported at the moment.
  1493.  
  1494.      The  IP  router is manually controlled - no rspf or rip,  or  even  ARP 
  1495.      requests.  This is because 32K of RAM does not allow such  niceties  as 
  1496.      queuing frames whilst waiting for address resolution.
  1497.  
  1498. 8. MISC
  1499.  
  1500.      Anyone  interested  in  a copy of the program, drop  me  a  message  on 
  1501.      GB7MXM.#36.GBR.EU Also, any suggestions for change gratefully received.
  1502.  
  1503. Dave G8KBB
  1504.      7, Rowanhayes Close
  1505.      Ipswich
  1506.      IP2 9SX
  1507.      England
  1508.